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Abstract: This chapter describes the ongoing process by which a multidisciplinary group 

at NASA’s Ames Research Center is designing and implementing a large 
interactive work surface called the MERBoard Collaborative Workspace. A 
MERBoard system involves several distributed, large, touch-enabled, plasma 
display systems with custom MERBoard software. A centralized server and 
database back the system. We are continually tuning MERBoard to support 
over two hundred scientists and engineers during the surface operations of the 
Mars Exploration Rover Missions. These scientists and engineers come from 
various disciplines and are working both in small and large groups over a span 
of space and time. We describe the multidisciplinary, human-centered process 
by which this MERBoard system is being designed, the usage patterns and 
social interactions that we have observed, and issues we are currently facing. 
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1. INTRODUCTION 

In 2003, NASA will send two robot rovers to explore the surface of 
Mars. Dubbed Mars Exploration Rovers (MER), they will operate as mobile 
science platforms and be the most capable systems ever sent to explore the 
surface of the Red Planet. With a planned mission lifetime of 90 days per 
rover, every day on the Martian surface represents a significant amount of 
time to gather important science data. 
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Rover acts as a remote field geologist on Mars 
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Figure 4-1. [Mars Exploration Rover has remote sensing instruments, and in-situ instruments] 

To maximize the productivity of the MER Rovers, the Mission 
Operations Team at the Jet Propulsion Laboratory (JPL) will communicate 
with the rovers every day. The science and engineering teams will receive 
data from the rovers, analyze the data, determine a strategy for operations for 
the next day, and develop daily command sequences. These command 
sequences will then be sent to the rovers for execution. 
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Figure 4-2. [Scientists and engineers on Earth communicate daily with the rover on Mars] 
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As part of a collaborative effort with JPL, NASA’s Ames Research 
Center initiated the Mars Exploration Rover (MER) Human Centered 
Computing (HCC) Project in the fall of 2000. Since that time, our team of 
cross disciplinary (computer science, anthropology, cognitive psychology) 
researchers has worked with MER science and operations team members 
applying ethnographic and human-computer interaction research methods 
and offering recommendations for the design of work processes, procedures 
and technology to help mission participants accomplish their work. Our goal 
is to help increase the science productivity of rover surface operations and 
the effectiveness of communication interactions and collaboration. The 
MERBoard, a new collaborative, situated, large screen technology for 
creating, accessing, displaying, annotating, sharing, distributing and saving 
information within the MER mission environment, is the principal technical 
innovation to come from this HCC effort. 

The MERBoard platform consists of a collection of large, interactive 
displays, networked together to share information. The displays will be 
situated on three floors of the Mission Support Area (MSA) at JPL. The 
MER HCC team developed custom software for this platform so that it will 
support users as they (a) create, save, retrieve and share information, (b) 
collaborate within small groups working around a single board, (c) 
participate in the collaborative work of large group interactions, as well as 
(d) share information between personal computers and the large displays. 



Figure 4-3. [The MERBoard's large touchscreen display creates an immersive environment 
for collaboration. The software is designed to support tasks in the target domain] 
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This chapter describes the domain in which the MERBoard will be used. 
We demonstrate how the research process led to the development of the first 
MERBoard design requirements and comment on how we believe the 
board’s development will come to provide a specialized “common 
information space” (Bannon 2000) (Bannon & Bodker 1997) (Bannon & 
Schmidt 1989) (Schmidt & Bannon 1992) within the mission. We describe 
the functionalities of the MERBoard and its iterative development process as 
it has been used by the Mars Rover mission team during training events. We 
then consider the potential use of these displays as new computing 
platforms, not desktops, but interactive platforms that support collaboration 
and can become ubiquitous computing platforms. 
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2. TYPES OF COLLABORATION THAT 
MERBOARD MUST SUPPORT 

For our team, the human-centered computing process involves 
understanding a domain by using a variety of ethnographic methods that 
include in-situ observations of the domain and working in partnership with 
domain members to determine information, communication and 
collaboration requirements. This section first describes the collaborative 
work processes that have been designed by the MER mission system and 
science team’s for their own use during the MER mission, in anticipation of 
their daily work of receiving rover data, analyzing it, devising a strategy for 
doing tele-robotic science and developing plans to carry out that strategy by 
sending commands to the rover. Then we describe some of our ethnographic 
findings from the early phases of MER mission design, especially in early 
test and training events, and we show the role that research played in 
developing the early design requirements for a new technology, the 
MERBoard. 


2.1 The Mission Operations Team 

The combined science and engineering team that will operate the rovers 
on Mars is called the Mission Operations Team. This team is composed of 
many sub-groups, such as the science team, the science operations support 
team, the spacecraft team, the mission planning team, the sequencing team, 
and others. All of these teams must work together to plan and conduct safe 
and productive rover operations. Since the focus of our work to date has 
been the science team, here we describe the science team structure for 
collaboration in the daily planning process. The Science team has been the 
major focus of our research, with a special interest in the structure of their 
work process and the need for collaboration in the daily planning process. 

2.2 The Science Team 

The MER science team will use the rover and its instruments to carry out 
the missions’ primary science objectives 
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Determine the aqueous, climatic, and geologic history of a site on 
Mars where conditions may have been favorable to the 
preservation of evidence of pre-biotic or biotic processes 

During the mission, science team members will formulate and test 
scientific hypotheses by first analyzing data they have requested from the 
rover on Mars and then developing new observations and activities for the 
rover to perform on the current sol. The science team is organized into 
smaller theme groups according to science discipline. Each theme group has 
members who work together to set goals and objectives for their discipline. 
Then a subset of the science theme group members meet together with 
engineers and other mission personnel in the Science Operations Working 
Group (SOWG), to develop an integrated set of objectives, observations and 
rover activity plans. The integrated science activity plan represents the 
overall goals of the SOWG. Developing these small and large group plans 
requires extensive communication and collaboration, both within and across 
the smaller theme groups and within the SOWG. The whole process must be 
completed each day within a few hours. Successful completion of this 
process requires access to both current and past information regarding 
mission decisions and any supporting rationale. 


2.3 Small Group Collaboration: Science Theme Groups 

The science team is organized into five theme groups: geology, 
geochemistry, soil, atmosphere and long-term planning. The first four are 
organized according to discipline, but the fifth theme group, long-term 
planning, has the job of analyzing the science process and rover operations 
from a strategic (longer term), scientific perspective. This group will keep 
track of the science decision process and aid in planning for longer-range 
activities that could cover periods of a few days to weeks or even months. 

The science team works in facilities designed to support collaboration in 
the decision making process. When science data is received from the rovers 
each day, individual instrument specialists and scientists will view the data 
and look for information and insights. Those scientists will then come 
together in a large Science Assessment Room in the Mission Support Area 
(MSA), specifically designed to support small group collaboration as well as 
collaboration across the five theme groups. In this room, there are five 
separate group areas, each with conference tables and good views of a large 
overhead projection screens that will project information relevant to each 
theme group’s discussions. 
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The work of the theme groups will be to analyze and discuss the data and 
relate it to that team’s current thinking as well as to any developing 
hypotheses. Then they will create a theme group activity plan consisting of a 
set of prioritized observations they would like the rover to make on the next 
sol (a sol is a Martian day). In addition to the collaboration within theme 
groups, group members will circulate within the room, sharing plans and 
strategies with other theme groups as they attempt to do some early 
coordination of their planning. 


Figure 4-4. [scientists working in a theme group] 


2.4 Large Group Collaboration: The Science Operations 
Working Group 

The goal of the Science Operations Working Group (SOWG) is to 
produce requests for an integrated set of observations and activities that 
represents the science team’s priorities for rover activities for the next day. 
Examples of activities include the gathering of data using a specific 
instrument and rover drives that take the rover to new areas and features of 
interest. The science teams’ requested plan is turned into commands and sent 
to the rover by the rover sequence team. 
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The SOWG meets after the science theme groups have developed their 
plans and priorities. Here the collaborative process will continue, but it takes 
on a decidedly different character. The SOWG group will have 
approximately forty members who can be active participants and another 
forty who are expected to be observers. To facilitate this large group 
collaboration, scientists will move to another room in the MSA that again 
has been specifically designed to support this type of collaboration. The 
work will be to develop an overall integrated science plan, deciding on 
which observations, if any, from the plans of individual theme groups will be 
incorporated. They will make this decision based on a discussion of the 
scientific rationale, objectives for the next sol’s operations, the overall 
strategic plan, and the need to meet the planning and engineering constraints 
set by current rover configuration and available rover resources, such as 
power and the bandwidth dedicated to data downlink. 

During this meeting all of the theme groups present their requests and 
priorities and develop together a single integrated science plan of associated 
rover instrument activities and movements that is acceptable to all theme 
groups and achieves agreed upon scientific objectives. In this meeting, the 
scientists also work with members of the engineering teams to begin the 
coordination of science plans and rover engineering plans that are being 
developed in tandem. This meeting is lead by a single person, the SOWG 
Chair, who is responsible for delivering a time-ordered list of requested 
science activities to an integrated team, that will then incorporate science 
and rover health and engineering plans into an integrated activity plan, do 
resource planning, turn the plans into commands, validate them and uplink 
them to the rover on Mars. 


3. OBSERVING THE WORK PRACTICE DOMAIN 

Our design philosophy calls for observation of existing work practice 
before proposing technology additions. In many domains we could simply 
observe existing work practice. This isn’t possible for Mars Rover Surface 
operations, as the landing doesn’t take place until 2004. We have been able 
to observe two rover field tests (Spring 2001 and Summer 2002), and two 
associated “Mars Yard” tests. It should be noted that the field tests are only 
partial representations of the real mission, as the timelines, work process and 
environments are approximations of real mission events and many of the 
tools and procedures that will be available for the mission, are still being 
designed. They are however, a valuable opportunity for gathering data by 
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observing users practicing mission processes. The primary goal of the field 
tests is to train the science team in tele-robotic operations. For the MER 
HCC team, the 2001 field tests were a primary source of data used to drive 
the early MERBoard design requirements. At the 2002 field tests we 
deployed two MERBoards and observed how they were used. The following 
summarizes what we observed at the 2001 field test. 

In field tests, the scientist engaged in real, not simulated, exploration. 
What made the explorations “real” was the use of a real rover, situated in the 
field, with science goals developed in real time for each test. The data used 
was real images from the field test rover. No simulated data was used. The 
science teams goal was to determine the location of a rover, which had been 
placed in a remote desert terrain, and create hypotheses about the geology 
and geochemistry of the surrounding area. During the tests, scientists worked 
together to make decisions about the types of scientific observations they 
wanted to do and worked with engineers, who were co-located in the same 
area, to create plans for doing science and commanding the FIDO (Field 
Integrated Design and Operations) rover to traverse and deploy a variety of 
instruments. During these tests, the JPL test team also introduced a variety of 
anomalies to train the scientists to deal with conditions they might encounter 
during Martian surface operations. 

During the field test, we used ethnographic methods to gather data, 
included observing work practice, taking field notes, doing formal and 
informal interviews, capturing video and still photos, and doing a subsequent 
analysis of the gathered data, including interaction analysis [Jordan xxx] of 
the video. 

The analysis revealed a variety of constraints on the science team’s 
collaborative process in those early tests. As scientists received data, 
analyzed it, and made their decisions, we saw limitations on their ability to 
communicate and exchange information; that is to view, share, present, save 
and thus refer to important electronic information and material artifacts in 
both small and large group settings. A ‘common information space’ was 
undeveloped. We define the common information space, expanding on 
Bannon [2000 p. 1,3], Bannon & Schmidt (1989), Bannon & Bodker (1997) 
and Schmidt & Bannon (1992)., as a communication and information space 
within a work system that is electronic but that can be supported by related 
communication events in co-located situations. It is a shared space where 
information ‘objects’ are accessible to all and communication, sharing and 
interpretation are supported as participants construct common interpretations 
and a common work purpose. 
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The benefits that come through location in physical proximity and a 
shared work environment were not enough to fully support the work that was 
being done in these early field tests. Even though the teams were working 
face to face, the pressure of the daily timeline required precise and rapid 
sharing of information of all kinds, verbal, electronic and hard copies so that 
the team could make decisions and execute a detailed plan of action. The 
scientists needed “multiple” and “intense” means of communication (Bossen 
2002, p.176) in order to develop the common interpretations (Reddy, 
Dourish, Pratt 2001) that are important to cooperative work and common 
information spaces. The fact that the science team shared a common 
expertise and pre-defmed goals contributed significantly to their ability to 
accomplish those goals (Bossen 2002) and was probably the major reason 
for their success during these early stages of mission design, when facilities, 
technology support and procedures were minimal and still in development. 

The first tests took place in the single room, among grouped tables, chairs 
and computer workstations whose configurations went through changes with 
each successive test based on our feedback and the feedback of others 
(Norris 2002). This was part of an effort to define the first requirements for 
the physical space that would eventually contribute to a Mission Support 
Area. FIG 5. 

We observed that the scientists had access to the following tools: 
personal laptop computers; flip charts; notebooks; print outs of schedules, 
images, and documentation; a twin-screened computer work station in each 
group area that was running the science activity planning software, still in its 
early stages of development; and three overhead projection screens that 
displayed the science activity planning software of the “uplink lead”, whose 
job was to represent the single, common activity plan the team was building 
each day, along with demonstrating models of rover activity. 
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3.1 Identifying Information and Collaboration Needs for 
a Common Information Space 

It was in the FIDO field test environment that we first identified 
information requirements that, in combination with design inspiration from 
IBM Almaden Research Center’s Blueboard [RussellOl], would lead to the 
development of the MERBoard, a technology that we believe will contribute 
greatly to enhancing communication and developing a common information 
space during MER surface operations. We began by identifying several areas 
that needed support: (1) information display, distribution and sharing, (2) a 
way to generate real time collaborative information representations (3) a way 
to annotate shared information (4) the ability to save or archive collaborative 
information generated during the tests and (5) remote viewing and control 
from one MERBoard to another and from a MERBoard to a personal 
computer. 


3.2 Information Sharing and Display 

The need for shared information displays became increasingly obvious 
over time, as members hung information and images on walls (Fig 6), draped 
images over flip chart stands, laid out large format images on their work 
tables (FIG 7), hung information created on flip charts in permanent display 
situations and used flip charts as a primary means of developing strategic 
rover plans and presenting them to the team. They also shared information 
with others simply by “calling out” information about mission updates, 
meeting times, and science and rover status and updates to the group as a 
whole. This practice left no information trail and created problems in the test 
when people who were not in the room failed to hear important information. 



Figure 4-6 . [The display and comparison of large format images] 
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Figure 4-7. [Note how the flip chart pages remain posted as a way of allowing information to 

continue to be accessible] 



Figure 4-8. [A scientist using flip charts to present during the 2001 FIDO Field Tests] 

An influencing factor that contributed greatly to our understanding of 
how important it would be for members to be able to share and display 
information was that during these tests there was minimal support for the 
most standard information sharing venues since copiers and printers were 
not easily accessible. (Note that the test area is quite different from the 
Mission Support Area being developed for actual Mars operations.) 
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Scientists needed to share information in both small and large groups. In 
small groups, they circulated images and printed information sheets; drew on 
scratch paper and yellow pads; turned notebooks and laptops for others to 
see; and pointed to the screen of the activity planning software. In large 
groups, they used flip charts; held up hard copies of images; used a laser 
pointer to point to information on the overhead projection screens; or simply 
verbally referred to their findings without the support of shared 
visualizations. Perhaps the most compelling instance of attempted 
information sharing from a requirements perspective was when scientists, 
who often had supporting scientific information on their laptops which they 
wished to share, held up the laptop for display to the group in an attempt to 
show the information to their colleagues. 

3.3 Creating Real-Time Representations While Doing 
Collaborative Work 

During the field tests, we saw a progression that began with the use of 
flip charts early in the planning process. The flip charts allow for free-form 
expression and were used for brainstorming, hypothesis creation and 
strategies for verification, as well as flow charts for long term planning (the 
team called these flow charts Sol Trees). For highly structured activities, 
such as the creation of rover timelines of activities and command sequences, 
a specialized mission tool was used. 

While flip charts support natural, rapid, handwritten representations, they 
do not allow for the embedding of related information such as images. They 
are difficult to store, retrieve and search over long periods of time, and they 
are not easily shared beyond team members who are co-located and in close 
viewing range. 
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3.4 Annotating Information 

While we saw scientists mark up notebooks and augment information in 
their computers, we saw only a few instances where people annotated the 
large hard copy images that were available. Informal interviews revealed that 
they were reluctant to mar the single copy of an image and yet they were 
consistently pointing to information, indicating that there was something of 
interest in it. 


4. DEFINING THE MERBOARD 

The MERBoard design is intended to assist the mission operations 
process by addressing the user needs that we observed in the tests, and those 
that we anticipate for the mission. Note that when we proposed the 
MERBoard, the critical path tools that would be used to build rover activity 
timelines and commands were already defined by JPL. By inserting the 
MERBoard into the mix of mission tools we propose to augment the teams 
planned work practice. 

Success will be measured, not only by acceptance and use, but also by 
providing needed capabilities that were non-existent or improving ones that 
were inefficient. As a software platform, its success will eventually be 
measured as well by the number of groups that adopt it as the mechanism for 
developing and deploying software in similar collaborative environments. 


4.1 Functionality 

In deriving the first functional requirements for the MERBoard, we were 
driven by the observations described above, and design inspiration from 
IBM’s Blueboard [RussellOl]. As there are many differences in operations 
between a field test and a real mission, we had to do our best to account for 
those differences. 

The initial MERBoard design specified the following functionality: 
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Data display, annotation and distribution, storage/retrieve 
capability for individuals and groups 
Ubiquitous access to information anywhere in the MER MSA 
Personal and group storage spaces, with mechanisms for getting 
information into and out of the MERBoard platform (e.g. from 
and to a laptop) 

Remote access and control, from board to board, and personal 
computer to board 

Simple, efficient mechanisms for capturing any data on the 
screen, and distributing that data using e-mail and personal/group 
storage spaces 

Following initial interactions with users, we added mission specific 
functionality: 

A Sol Tree Tool, this was requested by a science team member. 
Sol Trees (remember a Sol is a Martian Day) are flow chart 
representations of rover strategic plans, showing many possible 
alternatives for rover activities on each Sol. They were done 
manually on flip charts during the early field tests. We began by 
adding flowchart-like capabilities to the whiteboard, such as the 
ability to auto-attach lines between boxes and easily input text. 
This quickly evolved into a dedicated Sol Tree plug-in tool. The 
design is based on observed and planned work practice of the 
long term planning science theme group. Users can build flow 
charts of plans, then check a path on the plan to see how it affects 
mission goals. Mission specific features include the ability, to 
track Sol Type (a sol type means what is the rover doing on that 
day, e.g. driving, approaching or measuring a target). 


Throughout the process of proposing the MERBoard to the MER 
Mission, we emphasized that it would be easy to use, would require minimal 
training, and would have a level of simplicity comparable to a Palm Pilot. 
The users are supposed to feel that they are performing tasks, with their 
focus being the tasks, not the computer interface. Our challenge has been, 
and continues to be, how to design the collaborative functionality to best 
help the mission, while keeping the interface simple, and providing 
extensibility. 
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4.2 Functional Overview 

One of the keys to the success of the MERBoard is the integration of 
functionality into a collaborative workspace. We find issues, such as log ins 
and security, that have solutions we take for granted on the personal desktop, 
require re-design in a situated collaborative workspace. 
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Figure 4-10. [The MERBoard user interface, showing the display of science data using the 

browser] 


Figure 4-10 above, shows the major UI elements. A toolbar on the left 
side of the screen controls the modes. Functionally, a MERBoard mode is 
similar to an application. However, we expect that applications on a personal 
computer go through a startup process and are loaded by the user. For the 
MERBoard, the user accesses functionality by switching modes, but does not 
install and startup applications as on a personal computer. 

The top three modes. Whiteboard, Remote and Browser, are provided 
with all boards as these functions are considered fundamental to any 
collaborative activity. The next two buttons, are reconfigurable and may be 
specific to a board (the bottom button is user reconfigurable in real time). 
For example one board might have a data visualization mode for the geology 
group, whereas another might have a Sol Tree mode for the long term 
planners. 
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Below the mode selection buttons are meta-tools. Meta- tools operate 
across modes and function as global services. Screen capture and e-mail are 
shown in the figure. The people button opens and displays a directory to 
access people to display personal information in the collaborative 
environment (see Ubiquitous access to information, section 4.5). 


4.3 Data, Annotation and Distribution 

Based on our observations of the use of flip charts at FIDO, and users 
descriptions of past work practice, such as annotation of surface images 
during previous missions, we derived the requirement for a whiteboard that 
has, in addition to basic whiteboard functions, the ability to display, annotate 
and distribute data. Observed user work practice at FIDO showed, as part of 
the daily planning processes, science-brainstorming sessions done using flip 
charts and whiteboards. Most of the work done on the flip charts consisted of 
unstructured representations, showing early thinking in the formulation of 
hypotheses and science strategies. Following the brainstorming sessions, the 
scientists move to structured representations for integrating activity requests 
into a timeline, from which commands are generated. Critical path mission 
tools, such as JPL’s Science Activity Planner (SAP), support the structured 
activities, and indeed, impose mission-required structure on the users. 

Given that structured activities, of necessity, require users to think in a 
certain way (note that this structure is not arbitrary it is required for the 
generation of commands to the rover), it is our supposition that the 
MERBoard’s free-form tools, integrated with data display and annotation, 
will provide a means to support free-form thinking and representation for 
scientists and engineers during the mission, without the imposition of 
structured by the tools. Combined with the large interactive touch-screen, 
with its immersive qualities, we expect new types of interactions among 
team members and groups, in the display and analysis of data. 

Initial data access and display capability was provided by integrating a 
Web browser into the board. This allowed access to existing mission data 
sources. Figure 4-10 shows data displayed using the browser. We also 
integrated a mission specific tool called Data Navigator, developed by 
another group at Ames, to provide direct access to the mission database. 
Other means to display data on the board include uploading data to a 
personal or group MERSpace (section 4.4) or using remote access to display 
data from a personal computer or another board (section 4.6). 
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Any data that can be displayed on the board, in any mode, can be 
captured using the capture meta-tool, which automatically captures data to 
the whiteboard. From the whiteboard users can annotate the data, include it 
in drawings, brainstorms, hypothesis formation and validation, and any other 
whiteboard activity. 

Whiteboards may be saved to a users MERSpace (see section 4.4). To 
distribute a whiteboard to another user, just save it to their space in any 
public (non-secure) folder. Each MERSpace has an InBox folder, standard 
work practice for distribution of files to other users is to put it in their InBox. 
To distribute files outside of MERSpace, an e-mail meta-tool is provided. 
The whiteboards native file format is industry standard SVG. This allows 
editing of exported whiteboards in commercial applications that are SVG 
compatible. 


4.4 MERSpace - Individuals in a Collaborative Space 

Collaboration for MER requires access to information at many levels, not 
only from mission data sources, but personal data. At FIDO, we saw users 
analyze and create data representations on their personal computers. This 
data, like the mission data stored in the operational mission database, is part 
of the data set users require access to. To provide individual users with a 
means to bring their own data and information into the MERBoard’s 
collaborative workspace, we created the MERSpace, a place for users to 
store and retrieve their personal data. Rather than thinking of a personal 
computer, the user has a personal space in a collaborative computing 
environment. The current MERSpace provides folders, with an explorer type 
interface, a place for personal bookmarks and automatic one-button access to 
personal remote computers (see Section 4.6). To minimize complexity, we 
limited the folders to a single level. Users can create new folders, but not 
folder hierarchies. Figure 4-1 1 shows a users MERSpace. 

Each MERSpace user has a personal icon. Tapping on the icon selects the 
MERSpace. The icon also functions as a target, i.e. users can share 
information by dragging files between their icons. The icon identifies users 
for remote access requests and e-mail. Users put data into their MERSpace 
by uploading files from their personal computer using the MERSpace Web 
Page which provides access to MERSpace over the Web, and provides the 
user with an interface for uploading files from their personal computer to 
their MERSpace. 
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4.5 Ubiquitous Access to Information 

MER Mission operations will take place in the MSA (Section 2.3), which 
occupies three large floors of a building at JPL. It is the Mars Rover 
equivalent of NASA’s Mission Control Center in Houston, seen on TV 
during Shuttle Missions and the Apollo missions to the Moon. For the FIDO 
tests, the small physical space provided co-location for collaboration, so 
access to information across a large physical space was not an issue. This is 
not true for the mission, with its large MSA. 

To address the need for information access across the facility, we 
provide users and groups with access to their files from any MERBoard, a 
personal computer running the MERBoard personal client software, and the 
web. With ubiquitous access, a scientist moving between theme groups need 
not carry their personal computer with them to discuss their data. An 
engineer on a tiger team troubleshooting a problem can go from the 
sequence room to the spacecraft room and have access to the their data. 
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Figure 4-11. [MERSpace, showing the file explorer, personal bookmarks, and remote 

computer connect] 
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4.6 Remote Display and Control 

Our observations of team members attempting to show data on their 
personal computers to large groups, and user requests for being able to view 
and control one board from another, drove the requirement for remote 
capability. Remote allows one board to display and control another. The 
same capability works from a board to a personal computer. A user can 
display and control their PC from a MERBoard. Recall that a users 
MERSpace (section 4.4) automatically captures the IP address of users who 
are logged into their MERSpace Web Site. This allows for one button remote 
access to personal computers. Figure 4-12 shows a personal desktop being 
displayed on a MERBoard. 



Figure 4-12. [MERBoard remote mode, showing a desktop computer on the MERBoard] 


4.7 Hardware 

The MERBoard hardware is commercial off the shelf (with the exception 
of the stand which is commercially procured, but custom designed). The 
display is a plasma unit with a touchscreen overlay. A personal computer 
runs the MERBoard software, which is written in Java and can run on Linux, 
Mac OS-X, or Windows 2000. 
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Figure 4-13 . [The MERBoard 
hardware, with a user for scale] 


5. ACTUAL USE 

We’ve had two opportunities to observe the MERBoard in use by the 
MER Mission operations team in tra inin g. The first was in July of 2002, at a 
mission system thread test. The second was at the FIDO field tests in 2002, 
this was a follow on to the 2001 test, and provided a good opportunity to 
compare our design assumptions with actual use. Here’s a summary of our 
observations. 


5.1 Mission System Thread Test 

The mission system thread test was a test of the uplink processes for 
planning and sending commands to the rover. The users were a mix of 
scientists and operations engineers. The goal of the test was a successful 
uplink of commands. This was the first MERBoard deployment at JPL. As 
the use of the MERBoard in the mission is discretionary, its use was 
uncertain. There were several factors that affected MERBoard use relative to 
what we expect in the mission. First, many mission system tools are not yet 
complete. This proved to be a plus for MERBoard use, as the MERBoard 
was able to fill in for some of those tools. For this test, many MERBoard 
features were either incomplete or partially implemented. For example the 
remote capability was limited for this test. 
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The board received extensive use for this test. The primary use was 
display, capture and annotation of target data. Figure 21 shows the actual 
image used in the test, and the annotations showing target names and 
direction. 



Figure 4~14. [MERBoard annotated image from the mission system thread test] 


5.2 FIDO Field Test 2002 

In the summer of 2002, we observed the second FIDO field test, placing 
two MERBoards within the test facility. This test was larger than the first 
and was held in two rooms instead of one, with a larger number of 
participants. The test area now more closely simulated the design of the 
MSA by putting the larger three of the five science theme groups in one 
room, where they did their analysis and having them move to a larger room 
next door, where the other two theme groups were located, for the SOWG 
meeting. The MERBoard collaboration design assumes that each science 
theme group has their own MERBoard, however, due to the limitations of 
the facility, we were only allowed to place one MERBoard in each room. 

We used a variety of camera setups to capture interactions around the 
MERBoard and screen capture and logging setups to capture the activity on 
the board itself. We were able to observe and capture how the board was 
used, and to compare the actual use to the expected use. 
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5.2.1 Group Interactions Around the Board 

As we had anticipated, the board in the smaller room supported the work 
practice of the small groups and was initially used to access, and view 
images and mission relevant information. In fact, groups sometimes grew 
from shoulder to shoulder collaborators to over the shoulder collaborators as 
several people gathered at the boards to view images and create 
representations of interest. The large size of the board facilitated group 
interactions around images in several ways. First, the size and height of the 
board allowed people to easily view and interact with images in groups 
(Figure 4-15). 



Figure 4-15. [Using the board at the second FIDO Test] 

The ability of the board to display large scrollable images, combined with 
the touchscreen which facilitated interactions, allowed groups of scientists to 
view large terrains such that all of them could scroll through the terrain, 
point out features of interest and be active participants in the decision 
process of selecting features to be designated as targets. Contrast this with 
the more traditional means of a group of people using a personal computer or 
workstation to examine large terrain images. In that case several people are 
crowded around a relatively small screen, usually with one person 
controlling the computer. The size of the screen, locus of control, and type of 
interaction is changed significantly in this case. It’s also worth noting that 
large terrain and target images are displayed on the wall during field testing. 
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While this practice continued even in the presence of the MERBoards, the 
interaction and use of wall sized images is more constrained and less 
interactive. Scientists tended to view, rather than interact with, the wall 
mounted images. 

5.2.2 MERBoard as a Pervasive Device and Presentation Tool 

With the initial help of some early adopters, scientists used the pervasive 
set up of the two boards to create and save information in one room and then 
display it in the second room during the SOWG meeting. Figure 4-16 shows 
a scientist presenting to the SOWG. Over the period of the tests, the team 
members adapted their use of the MERBoard during the presentations, using 
content created on the MERBoards, content created on individual users lap 
tops and posted to MERSpace, as well as content created on users lap tops 
then shown and/or captured on the MERBoard using remote mode. Note that 
the presenter in figure 4-16 can show images to the group, and still be able to 
directly interact with the image on the screen. This is in contrast to the 
projection screens where remote interaction using a pointing device is 
required. 



Figure 4-16. [A scientist using the MERBoard to present to the science operations working 

group] 

As we had also anticipated, placement of the boards is crucial to their 
use. The long term planning group that was located closest to the board in 
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the smaller science assessment room rapidly became “owners” of that board. 
Additionally, we had provided some simple tools on the board (boxes and 
lines) to help this group create Sol Trees, a science process decision tree 
representation. Over the period of the test, the consistent day-to-day 
representation of this “tree” on the board formalized both the representation 
and the use of the board. From time to time, group members who were 
creating the tree would move to a large white board to make quick notes 
before inserting them into the decision tree. When the tree was running on 
one of the screens, other team members appeared reluctant to minimize it 
and use the board for other purposes. 


5.2.3 MERBoard and Traditional Media 

Note in figure 4-8 that flip charts were used as a means of developing 
content and presenting it to the SOWG at the 2001 FIDO Field Tests. The 
image in figure 4-8 shows a scientist presenting Sol Trees. As previously 
mentioned, the MERBoard design includes some basic features in the 
whiteboard specifically designed to facilitate the development of Sol Trees 
(this has since been extended to a dedicated sol Tree Tool). A key question 
for the MERBoard team going into FIDO was to what extent team members 
would use the MERBoard in place of a traditional medium, such as flip 
charts. Going in to the test we believed that an electronic medium, such as 
the MERBoard, must have several advantages to have any chance of 
replacing traditional media that team members were already comfortable 
using. The advantages that the MERBoard offered for Sol Trees were a large 
interactive workspace, the ability to easily save, recall and revise drawings, 
electronic drawing tools, and the ability to develop the Sol Trees on the 
board in the theme group area then easily bring the same drawing up on the 
board in the SOWG area for presentations to the group. 

Figure 4-15 shows the Long Term Planning Science Theme Group using 
the MERBoard to develop Sol Trees. Note how the board facilitates group 
interaction. For Sol Tree development, the users chose MERBoard over flip 
charts. The use pattern clearly showed that the MERBoards advantages were 
enough to get the team members to change their work practice and use an 
electronic medium in place of a traditional one. 
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6. THE XBOARD AND FUTURE WORK 

The MERBoard has evolved into the XBoard, an extensible architecture 
with an applications programmer interface and a plug-in developers kit. 
Three developers have started work on plug in applications. The XBoard is a 
platform for the development of large screen interactive collaborative 
applications. It is also the foundation for a ubiquitous computing structure 
for NASA. As part of the XBoard, we have designed a multi-center 
architecture (MCA). MCA will take the idea of ubiquitous computing 
beyond the MER Mission Support Area and extend it to conference rooms, 
design areas and work areas within NASA across NASA centers so that 
users and groups have access to their data from any XBoard within NASA. 

We also plan to develop a personal client. The idea is to have software 
that runs on a users personal computer to extend the MERBoard/XBoard 
environment. The client should provide access to the users MERSpace, 
seamless transfer of data from a personal computer to MERSpace, and easy 
remote access to the MERBoard/XBoard. 

We plan to deploy twelve MERBoards at JPL to support MER surface 
operations and training. We will observe how they are used and evolve the 
design based on what we see. No doubt the users will think of many things 
that we, as designers, have not. 


7. CONCLUSION 

The availability of large screen displays at affordable costs has 
created the beginning of a new class of computer. The collaborative 
interactive computer. The MERBoard, designed for specific tasks in 
a targeted domain and then deployed in that domain, has begun to 
accumulate enough use to give valuable data on user reaction to this 
new class of system. Additionally, based on our initial research, we 
suggest that this new class of system provides an electronic common 
information space that helps support collaborative work in intense, 
co-located situations requiring a variety of information inputs. We 
believe users will also create new work practices over time that 
makes maximum use of the MERBoard. Stay tuned for Mars Surface 
operations in 2004. 
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